Technical Field of the Invention
This invention relates generally to computing systems and more particularly to computing systems implementing software applications.
Description of Related Art
Many devices include a conventional computer architecture of a central processing unit, memory, a memory management unit, and a peripheral management unit. Such devices include computers, laptop computers, handheld computers, some cellular telephones, some video game devices, etc. A common theme for these devices is that they execute one or more algorithms to achieve a desired result and/or to perform a desired function. Other devices, while not having the conventional computer architecture, include a processing unit and memory to execute one or more algorithms. For example, some video game devices, some cellular telephones, some personal audio/video player, etc., include a processing unit and memory but not the conventional computer architecture.
Regardless of the specific architecture of devices that execute algorithms, they all include a hardware component and a software component. The software component generally includes three types of software: operating system (OS), application program interface (API), and applications. In general, an operation system has four primary functions: process management, memory management, file system management, and device management. Applications include user applications (e.g., word processing, calendar, spreadsheet, video game, etc.) and/or middle-ware applications (e.g., drivers, OS specific APIs, etc.).
The development of software for devices is an ever-increasing challenge since the devices are required to do more and to do it faster. Current software development techniques include a combination of manual steps and automated steps. In general, software development includes four primary steps: requirements, architecture, design, and code generation, each of which includes a combination of manual functions and automated functions. In addition, each primary step includes a form of testing.
An objective of the requirements step is to develop a list of requirements that identify the needs and/or conditions for the software development project to meet. The list of requirements may include functional requirements (e.g., what actions, tasks, and/or activities the system must do) and non-functional requirements (e.g., statements about the system such as performance levels, availability, reliability, etc.). A functional requirement contains a unique name, a description of the required behavior, and a rationale for the required behavior.
While there has been limit success in automating portions of the requirements steps (e.g., SPIN, PBS, Validator), it is still primarily a manual step. As such, modeling the requirements to test for incompleteness and/or inconsistencies is far from complete due the extremely large state space of the system and the lack of automated testing. Another issue with automating the generation of requirements is the inconsistency of language, descriptors, diagrams, etc. that are used to represent the requirements.
The architecture step of software development defines the structure of the system, which identifies software components and the relationship therebetween. Typically, the software architecture is organized in views that may include functional and/or logical views, code and/or module views, development and/or structural views, concurrency, process and/or thread views, physical and/or deployment views, user action and/or feedback views, data views, etc.
With respect to the architecture step, there have been several languages developed to describe software architectures (e.g., architecture description languages (ADL)). There are various implementations of the ADLs including AADL, Wright, Acme, xADL, Darwin, and DAQP-ADL. While such automation exists, they are still prone to manual errors and incompleteness of testing. In addition, they lack a standardized language, which makes utilization of the software architecture by the other primary steps of software development a manual function.
The design step of software development defines a low-level component design for the system. The design step may also address algorithm implementation issues of the system and architecture issues using one or more design concepts (e.g., abstraction, refinement, modularity, software architecture, control hierarchy, structural partitioning, data structure, software procedure, and/or information hiding). The resulting design may be platform specific or independent and it includes story-board(s), modeling language model(s), and/or flow chart(s).
With respect to the design step, there have been several modeling languages developed to produce the modeling language model. The modeling languages may be graphical or textual for various types of design step objectives. For example, BPMN (business processing modeling notation) is a process modeling language; EXPRESS is a general purpose data modeling language; EEML (extended enterprise modeling language) is a business process modeling language that applies across a number of layers; FMC (fundamental modeling concepts) is a modeling language for software intensive systems; DEF is a family of modeling languages; JSP (Jackson structure programming) is a method for structured programming of data stream structure and programming structure correlation; design description language for modeling large object orientated programs (e.g., JAVA, C++, etc); UML (unified modeling language) describes a software design structurally and behaviorally and includes graphical notation; and alloy describes a software design structurally and behaviorally and includes a concise language based on a first order relational logic.
The code generation step of software development includes writing source code in a programming language to perform the desired behaviors defined in the previous software development steps. The programming language may be of one or more programming language categories that includes: Array languages (e.g., Fortran 90), Aspect-oriented languages (e.g., Aspect C++), Assembly languages, authoring languages, command line interface languages, compiled languages (e.g., C++, JAVA, etc.), concurrent languages, curly-bracket languages, data flow languages, data-oriented languages, data structured languages, declarative languages, esoteric languages, extension languages, fourth generation languages, functional languages, interactive mode languages, interpreted languages, iterative languages, list based languages, little languages, logic based languages, machine languages, macro languages, meta-programming languages, multi-paradigm languages, numerical analysis, non-English based languages, object oriented class based languages, object oriented prototype based languages, off-side rule languages, procedural languages, reflective languages, rule based languages, scripting languages, stack based languages, synchronous languages, syntax handling languages, visual languages, Wirth languages, and XML based languages.
The code generation step of software development also includes requirements analysis and testing the source code. Requirements analysis of the source code may be done using Use Case analysis to verify that source code achieves the desired behavior and avoids dead locks. Testing of the source code generally includes value modeling, implementation, and debugging. Modeling of source code may be done using one of many modeling techniques (e.g., object-oriented analysis and design, model driven architecture, etc.).
While the above described software development process enables the creation of significant amounts of software annually, it is far from an optimal process and is far from fully automated or near-fully automated. Since each primary step (e.g., requirements, architecture, design, and code generation) includes multiple manual operations and, for the automated operations, has little to no standardized implementation requirements and/or formatting requirements, each primary step is almost a completely autonomous process. As such, automation of the software development process using the current techniques is highly improbable due to the autonomy of each primary step, the many manual operations, and/or other factors.